home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / May 96 / 32-bit coordinate space < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  2.1 KB  |  [TEXT/ttxt]
  1. Subject:     32-bit coordinate space
  2. Sent:        5/23/96 3:00 PM
  3. Received:    5/23/96 3:11 PM
  4. From:        Gary Ashcraft, ashcraft@dharbor.com
  5. Reply-To:    ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. Like everyone knows, both ODF and OpenDoc use a 16.16 fixed-point
  9. coordinate system.  Without changing the coordinate mapping, the maximum
  10. number of pages in the vertical direction is about 40 pages.  While this is
  11. enough for a leaf part or ODF Draw, many container (root) parts display
  12. content that can easily exceed this limit.  Text processors and
  13. spreadsheets are examples of parts that exceed this limit.
  14.  
  15. Both OpenDoc and ODF claim that you can change this size by scaling your
  16. coordinates.  Henri has suggested that we just view the fixed-point numbers
  17. as 24.8 fixed-point numbers.  Kurt Piersol (in Develop 21) suggests using
  18. fixed-point inches instead of points.  We've been spending the past couple
  19. of days looking into supporting a larger view space.  It turns out that
  20. it's not that simple.
  21.  
  22. Simply changing the scaling is only part of the problem.  The other part of
  23. the problem is how to handle the 32-bit coordinate space, since QuickDraw
  24. is limited to 16 bits.  We need 32-bit coordinates, then a way to map them
  25. back & forth from 16-bit space when we render, handle mouse clicks, etc.
  26.  
  27. We've looked at MacApp and PowerPlant; they both use port tiling at 1K
  28. (MacApp) and 16K (PowerPlant) to achieve canvasses of arbitrary size.
  29.  
  30. We've tried subclassing FW_CView, keeping our own member variable that's in
  31. 32-bit space, but it looks like we'll have problems, since all of the
  32. coordinate conversion methods, like FrameToView and ViewToFrame, are not
  33. declared virtual.
  34.  
  35. What we're trying to do is something that a lot of developers will have to
  36. deal with.  This problem should be solved once in ODF, like MacApp has
  37. done.  Until ODF solves this problem, it can't be used for serious
  38. spreadsheets or text processing.
  39.  
  40. In the meantime, can you give us a recipe that provides a solution using ODF R1?
  41.  
  42. Regards,
  43.   The Digital Harbor Development Team
  44.  
  45.  
  46.